Service-oriented modeling

Service-oriented modeling is the discipline of modeling business and software systems, for the purpose of designing and specifying service-oriented business systems within a variety of architectural styles, such as enterprise architecture, application architecture, service-oriented architecture, and cloud computing.

Any service-oriented modeling methodology typically includes a modeling language that can be employed by both the 'problem domain organization' (the Business), and 'solution domain organization' (the Information Technology Department), whose unique perspectives typically influence the 'service' development life-cycle strategy and the projects implemented using that strategy.

Service-oriented modeling typically strives to create models that provide a comprehensive view of the analysis, design, and architecture of all 'Software Entities' in an organization, which can be understood by individuals with diverse levels of business and technical understanding. Service-oriented modeling typically encourages viewing software entities as 'assets' (service-oriented assets), and refers to these assets collectively as 'services'.

Contents

Popular approaches to service-oriented modeling

There are many different approaches that have been proposed for service modeling, including SOMA and SOMF.

Service-oriented modeling and architecture (SOMA)

IBM announced Service-Oriented Modeling and Architecture (SOMA) as the first publicly announced SOA-related methodology in 2004.[1] SOMA refers to the more general domain of service modeling necessary to design and create SOA. SOMA covers a broader scope and implements service-oriented analysis and design (SOAD) through the identification, specification and realization of services, components that realize those services (a.k.a. "service components"), and flows that can be used to compose services.

SOMA includes an analysis and design method that extends traditional object-oriented and component-based analysis and design methods to include concerns relevant to and supporting SOA. It consists of three major phases of identification, specification and realization of the three main elements of SOA, namely, services, components that realize those services (aka service components) and flows that can be used to compose services.

SOMA is an end-to-end SOA Method for the identification, specification, realization and implementation of services (including information services), components, flows (processes/composition). SOMA builds on current techniques in areas such as domain analysis, functional areas grouping, variability-oriented analysis (VOA) process modeling, component-based development, object-oriented analysis and design and use case modeling. SOMA introduces new techniques such as goal-service modeling, service model creation and a service litmus test to help determine the granularity of a service.

SOMA identifies services, component boundaries, flows, compositions, and information through complementary techniques which include domain decomposition, goal-service modeling and existing asset analysis.

SOMA Life cycle modeling activities

Service-oriented Modeling and Architecture (SOMA) consists of the phases of identification, specification, realization, implementation, deployment and management in which the fundamental building blocks of SOA are identified then refined and implemented in each phase. The fundamental building blocks of SOA consists of services, components, flows and related to them, information, policy and contracts.

Service-oriented modeling framework (SOMF)

Service-Oriented Modeling Framework (SOMF) Characteristics

The Service-Oriented Modeling Framework (SOMF) has been proposed by author Michael Bell as a holistic and anthropomorphic modeling language for software development that employs disciplines and a universal language to provide tactical and strategic solutions to enterprise problems.[2] The term "holistic language" pertains to a modeling language that can be employed to design any application, business and technological environment, either local or distributed. This universality may include design of application-level and enterprise-level solutions, including SOA landscapes or cloud computing environments. The term "anthropomorphic", on the other hand, affiliates the SOMF language with intuitiveness of implementation and simplicity of usage. Furthermore, The SOMF language and its notation has been adopted by Sparx Enterprise Architect modeling platform that enables business architects, technical architects, managers, modelers, developers, and business and technical analysts to pursue the chief SOMF life cycle disciplines.

The service-oriented modeling framework (SOMF) is a service-oriented development life cycle methodology, a discipline-specific modeling process. It offers a number of modeling practices and disciplines that contribute to a successful service-oriented life cycle development and modeling during a project (see image on left).

It illustrates the major elements that identify the “what to do” aspects of a service development scheme. These are the modeling pillars that will enable practitioners to craft an effective project plan and to identify the milestones of a service-oriented initiative—either a small or large-scale business or a technological venture.

The provided image thumb (on the left hand side) depicts the four sections of the modeling framework that identify the general direction and the corresponding units of work that make up a service-oriented modeling strategy: practices, environments, disciplines, and artifacts. Remember, these elements uncover the context of a modeling occupation and do not necessarily describe the process or the sequence of activities needed to fulfill modeling goals. These should be ironed out during the project plan – the service-oriented development life cycle strategy – that typically sets initiative boundaries, time frame, responsibilities and accountabilities, and achievable project milestones.

SOMF Language modeling generations

SOMF introduces a transparency model by enabling three major modeling time frames, often named modeling generations:

These three unique implementation generations can be viewed by SOMF diagrams and their corresponding perspectives to help practitioners to depict business and architectural decisions in the past, current, and future implementations. For example, an architect and a developer can describe the evolution of a system or an application since inception, and explain what were the architecture best practices that drove alterations to these software entities. This capability enables transparency of design and implementation. On the business side, modeling generations can help estimate return on investments and business value. Traceability of business investments and justifications to business initiatives can also be depicted by employing these modeling generations.

SOMF Transformation Models

SOMF offers eight models of implementation, also known as "Bell's Transformation Models", as depicted in the displayed image named SOMF Transformation Models. Each of these units of work, namely models, identify the methodology, process, platform, best practices, and disciplines by which a practitioner ought to accomplish a modeling task during a project. The illustrated ninth model is the Governance Model, which should be employed to manage the other eight models.

Consider the overall charter of the SOMF implementation models:

Discipline-specific modeling

SOMF is driven by the development process of services. This approach, also named discipline-specific modeling (DspM), enables business and information technology professionals to focus on modeling deliverables that correspond to a specific software development life cycle stage and event.

The service-oriented modeling framework (SOMF) introduces five major life cycle modeling activities that drive a service evolution during design-time and run-time. At the design-time phase a service originates as a conceptual entity (conceptual service), later it transforms into a unit of analysis (analysis service), next it transitions into a contractual and logical entity (design service), and finally is established as a concrete service (solution service). The following identify the major contributions of the service-oriented modeling activities:

Methodological issues

SOMF Modeling styles

How can a practitioner model a computing environment? In what type of forms can a group of services be arranged to enable an efficient integrated computing landscape? What would be the best message routes between a service consumer and provider? How can interoperability hurdles be mitigated?

SOMF provides five major software modeling styles useful throughout a service life cycle (conceptualization, discovery and analysis, business integration, logical design, conceptual and logical architecture). These modeling styles: Circular, Hierarchical, Network, bus, and Star, are illustrated by corresponding "modeling beams" --connectors that link services to each other, can assist a software modeler with the following modeling aspects:

In the illustration on the right you will find the major five service-oriented modeling styles that SOMF offers. Each pattern identifies the various approaches and strategies that one should consider employing when modeling a service ecosystem.

SOMF Modeling asset patterns

The service-oriented modeling framework (SOMF) introduces four major software formations. These structures are software entities that habitually exist in our computing environments. In addition, the notion of a software component is further abstracted and represented by the universal "service" term, which can represent any organizational software asset, such as an object, a software module, a library component, an application, a business process, a database, a database store procedure or trigger, an ESB, a legacy implementation, a Web service, and more. Again, any of these software entities can be named "service". The image bellow illustrates these asset patterns.

Thus, a service is classified by its contextual and structural attributes:

The below image illustrates these SOMF assets that are being modeled during the analysis phase of a project.

SOMF Modeling notation

As previously discussed, each SOMF life cycle discipline also offers a specialized notation. For example, the service-oriented discovery and analysis discipline provides a notation to help model the analysis and identification of services.[3] In addition, during the design phase the SOMF design notation offers symbols to help model a logical design, design composition, and a service transaction model.

Let us take a look at the service-oriented discovery and analysis modeling notation. During the service identification and inspection a practitioner should pursue two types of modeling tasks: (1) Contextual analysis and modeling, and (2) Structural analysis and modeling. These activities are performed to produce a service-oriented analysis proposition.

The below illustration identifies the contextual analysis and modeling operations (represented by analysis symbols)that can be employed to draft an analysis proposition diagram. These operations promote the core service-oriented analysis discipline best practices.

Here is a short description for these symbols:

The below illustration, on the other hand, depicts the service-oriented structural analysis and modeling notation.

Here is a short description for these symbols:

Service-Oriented Conceptualization

The service-oriented modeling framework (SOMF) advocates that practitioners devise conceptual services to bridge the communication gaps in an organization. These conceptual entities foster the creation of a common language, a vocabulary that can be used during projects to encourage asset reuse and consolidation. One of the most important aspects of the conceptual service paradigm is that it provides direction and defines the scope of a project or a business initiative.

The conceptualization process then identifies six major “tools” that can facilitate the development of conceptual services.[5]

Examples

Let us now view a number of service analysis modeling examples.

SOMF Cloud computing modeling capabilities

The SOMF cloud computing modeling notation, also known as CCMN, helps illustrate a service architecture scheme whose participating services interact and collaborate in a cloud boundary or beyond. “Cloud boundary” pertains to cloud offerings, which typically provide software, infrastructure, and platform type of services. The term “beyond”, however, implies that any consumer, such as organizations, applications, or remote services can also be a part of the cloud computing venture if they subscribe to the cloud’s services.

This overall servicing vision embodies the general notion: “Everything is a Service”, as illustrated on the far right. The ability to abstract services in spite of their location, interoperability challenges, or deployment difficulties, the SOMF cloud computing model represents an elastic cloud computing environment, nimble enough to adapt to changes, and meet time-to-market.

Cloud Computing Modeling Examples

The introduced examples illustrate cloud design diagrams produced in various software development life cycle stages. In addition, these examples introduce three major cloud modeling spaces, each of which helps modelers to describe service interoperability, integration, message exchange, and collaboration in a deployment environment:

References

  1. ^ Bieberstein et al., Executing SOA: A Practical Guide for the Service-Oriented Architect (Paperback), IBM Press books, 978-0132353748
  2. ^ Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN 978-0-470-14111-3. 
  3. ^ Michael Bell (2010). SOA Modeling Patterns for Service-Oriented Discovery and Analysis p.223, 305
  4. ^ a b Michael Bell (2010). SOA Modeling Patterns. p. 223
  5. ^ Michael Bell (2008). Service-Oriented Modeling p.88-89

Further reading

External links